home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / applications / 2854 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.6 KB
  1. Path: yama.mcc.ac.uk!dmu!mkcsug06
  2. From: hcm94rp2@dmu.ac.uk (Richard Perrott)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: Re: MUI
  5. Date: Tue, 05 Mar 96 23:13:58 GMT
  6. Organization: De Montfort University
  7. Message-ID: <4hi0ej$906@macondo.dmu.ac.uk>
  8. References: <4h22lr$1d8@ns.hookon.be> <singh-0404952044330001@pool5-028.wwa.com> <4hdstb$2aj@ringer.cs.utsa.edu>
  9. NNTP-Posting-Host: mkcsug06.mk.dmu.ac.uk
  10. X-Newsreader: News Xpress Version 1.0 Beta #4
  11.  
  12. Glossary:
  13.     MFU    Massive Fuck Up, a better name than 'BUG' for programming
  14.         defects since it forces the programmer to accept 
  15.         responsibility for them not just call them a 'feature'.
  16.         The term is taken from a excellent book on bug         
  17.         prevention and debugging.
  18.  
  19. In article <4hdstb$2aj@ringer.cs.utsa.edu>,
  20.    jpeacock@ringer.cs.utsa.edu (Jason Peacock) wrote:
  21.  
  22. .cut..
  23. >   I really don't get this.  I don't see how my 40Mhz 68030 could be
  24. >   faster than your 68040 at any speed.  MUI 2.x was a bit slow but
  25. >   still tolerable and MUI 3.x feels about 2-3 times faster, which is
  26. >   nice.  The other stuff out there (gtlibrary, BGUI, Triton, and internal
  27. >   mechanisms) doesn't feel any faster than MUI anymore.
  28. .cut..
  29. I haven't noticed much if any speed improvement and MUI is the slowest of 
  30. numerous GUI libraries I have tried so far, even MUI V3.3.
  31.  
  32. >
  33. >: It really boggles my mind why with a nice, small, fast OS like the Amiga
  34. >: so many programmers want to tether it to an interface as sluggish an MUI.
  35. >
  36. >   I've always wondered if people thought MUI was so slow on a nice, small,
  37. >   fast OS like the Amiga, imagine what it would be like if someone tried
  38. >   to implement something similar for Windows or Macintosh.
  39. >
  40. They'd accept it since they are used to sluggish GUI's which crash due to 
  41. MFUs, e.g. it needs a Pentium to get acceptable GUI speed for most 
  42. applications in Windows 3.1 and they can still get btrieve crashes. 
  43. By acceptable I mean when they attempt to multitask.
  44.  
  45. >: It's a cruel twist of fate that MUI has become so popular -- I
  46. >: dunno, maybe programmers are too lazy to write their own boopsi gadgets?
  47. >
  48. >   Why re-invent the wheel?  If someone's already done it, use it.  It
  49. >   does no good to have a "not invented here" attitude.  Why waste
  50. >   time building another boopsi gadget if one that meets your needs
  51. >   already exists for use?
  52. >
  53. Granted re-writing boopsi gadgets is questionable, but having a _very_ slow 
  54. handler code, MUI, is down right stupid since the client program will be 
  55. annoyingly slow. 
  56.  
  57. >: It beats me, but all in all, after using MUI on my brother's 2000/020 it
  58. >: makes me feel sorry -- I always thought the amiga community was the one
  59. >: group that took care not to make older machines obsolete.  The "hey if
  60. >: they user feels the interface is kludgy, he or she needs more horsepower"
  61. >: theory is way too MicroSoft/Intel for my liking. :(
  62. >
  63. >   I still think we do.  Amiga Technologies is coming out with the
  64. >   Amiga Surfer package which will be a 14Mhz 68ec020 A1200 running
  65. >   Internet software that requires MUI (included) to run.  AT must
  66. >   think that the A1200 is up to handling MUI.
  67. >
  68. They made a mistake in under-estimating resources before e.g. not enough 
  69. memory for a certain graphics tool on HD.  Also they probably wanted to rush 
  70. out some response just to say they were first.
  71.  
  72. >   Besides, there's only so much one can do with limited resources.  I
  73. >   remember a program called Paperclip Publisher for the C64.  It
  74. >   amazed me with the amount of features they were able to put into a
  75. >   computer that had a single 140KB floppy drive, 64KB RAM, and a 1Mhz
  76. >   processor.  I was not amazed, however, that the program ran with all
  77. >   the speed of molasses in January.  GEOS for the C64/C128 is another
  78. >   example.  These computers were being pushed to their limits by these
  79. >   programs and the speed was barely tolerable.
  80. >
  81. >   If you want more features, and have them done well, you can't expect
  82. >   the hardware to remain static and still cope with growing software.
  83. >
  84. I have an A1200 with 4MB _extra_ Fast Mem, 50MHz 030/MMU, and 1GB HD, not a 
  85. cheap set up.  After my KS is cached, buffers for 3 AFS-Pro partitions, and a 
  86. few commodities I only have 1.5MB Chip and 2MB Fast left.  I think it is 
  87. reasonable to expect to run most programs in 3.5MB of RAM.
  88.  
  89. Most programs run comfortably in this environment, but MUI applications are 
  90. still noticably sluggish.  For a directory tool e.g. RO where dos is handling 
  91. most of the actual work, for the GUI to be sluggish is a disappointment.  RO 
  92. is hardly used now since the fancy front end takes up too much space and some 
  93. MUI objects actually make the interface harder to use than the equivalent 
  94. Gadstools/boopsi one.  I have used computers for over 10 years and done a GUI 
  95. design course so I think know what I'm talking about.
  96.  
  97. As for memory:
  98. MUI seems to keep RAM for items even when those items are not being used, and 
  99. doesn't flush them until you close and flush MUI.  If MUI would flush them 
  100. when it was still loaded then I wouldn't _have_ to do this manually.
  101.  
  102. Also since MUI and its classes have so many data stored in codes hunks I 
  103. can't use VMM for a lot of the data parts, since MUI code and applications 
  104. won't tolerate being in virtual memory.  Most normal applications will take 
  105. advantage of VMM since a lot of their data is in data hunks.
  106.  
  107. Also despite MUI has all this junk cached in memory it runs slower than 
  108. applications which setup stuctures only _when_required_.
  109.  
  110. IMHO
  111. Richard
  112.  
  113. ----------------------------------------------------------
  114. Richard Perrott        | Amiga Forever!
  115. hcm94rp2@dmu.ac.uk    | If the answer is Microsoft or
  116. *nobody@REPLAY.COM is in| Apple you're asking the wrong
  117. my kill file.        | question.
  118.